home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 001195_murphy@dccs.upenn.edu _Thu May 27 15:24:42 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  7KB
  1. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  2.     id AA17140; Thu, 27 May 93 15:24:42 MET DST
  3. Received: from NOC4.DCCS.UPENN.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  4.     id AA25062; Thu, 27 May 1993 15:46:08 +0200
  5. Received: from LAM.DCCS.UPENN.EDU by noc4.dccs.upenn.edu
  6.     id AA25833; Thu, 27 May 93 09:46:05 -0400
  7. Return-Path: <murphy@dccs.upenn.edu>
  8. Received: by lam.dccs.upenn.edu
  9.     id AA03278; Thu, 27 May 93 09:46:04 -0400
  10. Posted-Date: Thu, 27 May 93 09:46:03 -0400
  11. Message-Id: <9305271346.AA03278@lam.dccs.upenn.edu>
  12. To: www-talk@nxoc01.cern.ch
  13. Cc: litwack@dccs.upenn.edu
  14. Subject: Keeping HTML Simple & Format negotiation between Browser & Server
  15. Date: Thu, 27 May 93 09:46:03 -0400
  16. From: murphy@dccs.upenn.edu
  17. X-Mts: smtp
  18.  
  19.  
  20. There's been a discussion on www-talk about how complex HTML should
  21. become -- and the building opinion seems to be: keep HTML simple, and
  22. allow more complicated formats to be embedded "in-line" in the HTML,
  23. and negotiated between the server and the client.
  24.  
  25. Dave Raggett:
  26. >> My suggestion is that we follow the approach taken with the PC and allow
  27. >> object level embedding in HTML. This basically means you keep HTML small
  28. >> and simple while allowing people to embed figures etc. in a foreign format.
  29. >> The embedding uses a link like Mosaic's <IMG> tag. The embedded data can
  30. >> be sent along with the main document using MIME's multipart capability.
  31. >> This approach also allows simple browsers to negotiate the format, so
  32. >> that the server can be asked to render equations into bitmaps etc.
  33. >> 
  34. >> This approach avoids the danger of HTML being continuously extended to
  35. >> support an every increasing variety of needs. By decoupling HTML
  36. >> from special purpose formats, I believe that the latter can evolve
  37. >> faster and more effectively, than if they were tied to revisions to HTML
  38. >> itself. 
  39. >> 
  40. >> That said, I am drafting a proposal for HTML+ (a superset of HTML) and
  41. >> would be happy to draft ideas for supporting equations in a presentation
  42. >> independent format. I don't think we should tie ourselves to Tex's approach,
  43. >> but should take the good ideas from a wide variety of sources: Tex, eqn,
  44. >> Microsoft Word, Mac, ...
  45. >> 
  46. >> Comments please!
  47. >> 
  48. >> Best wishes,
  49. >> 
  50. >> Dave Raggett,
  51.  
  52. So for example, the client could send a list of pre-defined formats to
  53. the server (e.g. IMG, TeX, PostScript, etc), and then the server can
  54. choose among different formats of the same item embedded in the
  55. document to give the client what it can handle.  Sometimes, the server
  56. might not be able to convert the one of the things that the client
  57. (browser) can deal with, and then it's up to the browser to display an
  58. intelligent message about it, perhaps even giving the user information
  59. so he can find software for his desktop environment which DOES deal
  60. with that format.
  61.  
  62. Elements needed:
  63.  
  64. 1) an ever-growing dictionary of pre-defined format names and
  65. agreement on what those format names mean.  It has to be ever-growing
  66. because it's a fact of life -- there's always going to be new types of
  67. data formats coming onto the scene.  The server and the browser
  68. (client) both need access to this dictionary, perhaps getting a new
  69. version of it every once in a while (either automatically, or perhaps
  70. upon the user's request)
  71.  
  72. 2) The document format (HTML, HMML, whatever) needs to accomodate
  73. documents which have multiple items in it, which could be different
  74. types, such as an embedded graph and a mathematical formula.  AND each
  75. of the items themselves COULD be expressed in a number of different
  76. format types.  The information which the two alternatives convey would
  77. not have to be exactly equivalent -- sometimes a picture is worth a
  78. thousand words!  But if text is all your device can display, you might
  79. settle for the words.  The person who maintains the document can put
  80. both text & image in the document, and the image would be displayed if
  81. possible.
  82.  
  83. 3) Either:
  84.  
  85. a) The protocol which the server and the client use must allow the
  86. client to tell the server which pre-defined format types it can deal
  87. with, and then the server can send back a version of the document
  88. which contains those types.
  89.   OR
  90. b) The protocol has no negotiation; the server sends back the entire
  91. document and the client can sort it out.  This COULD be costly in
  92. terms of network bandwidth and computing resources at the desktop...
  93.   OR
  94. c) Is there another alternative?
  95.  
  96.  
  97. 4) Whichever way is chosen for #3, the browser (client) needs a
  98. lot of information in it about what the desktop environment is like
  99. (e.g. it can display postscript by starting up XPostScriptViewer
  100. with arguments "-f <filename> -mono", it can display bitmap images
  101. by starting up "xv <filename>", it can display bitmap images
  102. by starting up GIFFER,  etc).
  103.  
  104.  
  105. 5) The user will probably want to be able to customize how the browser
  106. chooses desktop applications (e.g. he installs a new image viewer, or
  107. a device driver & software for sound playback).
  108.  
  109.  
  110. The complexity of how to translate and display these "foreign" formats
  111. could then be shifted to the OTHER applications in the desktop
  112. environment, and kept out of the browser, and out of HTML.
  113.  
  114.  
  115. Problems with this model:
  116.  
  117. 1) If the browser starts up another application to handle a portion of
  118.    the document in a foreign format, what happens if that item in the
  119.    document was SUPPOSED to be in-line with other portions of the
  120.    document?  How does the browser pull it back into the display of
  121.    the document and make it part of the whole?
  122.  
  123.    Perhaps 
  124.    a) There's a way to tell the application to dump the results into a
  125.    file or a pipe, which the browser then reads & incorporates into
  126.    the document or
  127.  
  128.    b) HTML accomodates embedded binary data, with a tag introducing it
  129.    as sound, or a bitmap image, or whatever, and an integer which says
  130.    how long the binary data stream is in bytes.  But I believe the
  131.    assumption here is that the server MUST know about the devices that
  132.    are at the desktop in order to generate, e.g. a reasonable image.
  133.  
  134.  
  135. 2) What if one wants to put hot-spots (links) into one of these
  136.    foreign format objects?  For example, suppose one wants the user to
  137.    be able to point & client on a portion of the mathematical formula,
  138.    which is linked to another mathematical formula (or a graph, or a
  139.    piece of text, etc) which more fully explains it?
  140.  
  141.  
  142. ________________________________________________________________________
  143. |                                                                      |
  144. | Linda A Murphy                       Internet: murphy@dccs.upenn.edu |
  145. | Network Engineering       Data Communications and Computing Services |
  146. | University of Pennsylvania                            (215) 898-9534 |
  147. |______________________________________________________________________|